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[57] ABSTRACT 

The present invention provides a method and apparatus for 
measuring transaction response times. The method and 
apparatus can identify s ervice request sequences cor re- 
sponding to a transaction and the start and stop times for the 
transaction. The invention can be applied nojn-intrusively/ 
non-invasively to the service packejsjromjiuinicated 
between a source and destination node. 

22 Claims, 17 Drawing Sheets 



CLIENT 
COMPUTER 
28 



24 



SERVER 
COMPUTER 
32 



RECORDING 
DEVICE 
20 



MONITORING 
COMPUTER 
36 



01/29/2003, 



EAST Version: 



1.03.0002 



U.S. Patent Nov. n, im sheet i of 17 5,838,920 



CLIENT 
COMPUTER 
28 




24 

. I 


SERVER 


( 




COM PI ITFR 
32 




RECORDING 
DEVICE 
20 














MONITORING 
COMPUTER 
36 





Fig. 1 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 2 of 17 



5,838, 



26a 



CLIENT 
COMPUTER 
28 



RECORDING 
DEVICE 
20a 



SERVER 
COMPUTER A 
32a 



SERVER 
COMPUTER C 
32c 



24a 



1 



22 



SERVER 
COMPUTER B 
32b 



MONITORING 
COMPUTER 
36 



RECORDING 
DEVICE 
20b 



Fig. 2 




24b 



26b 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. n, ms sheet 3 of 17 5,838,920 



NODE ADDRESS 


PORT NO. 


INFORMATION TEXT 


40 


44 


48 



38 



Fig. 3 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent 



Nov. 17, 1998 Sheet 4 of 17 



5,838,920 



A A 



STOP 
TIME 



TIME 
A 



SERVICE 
REQUEST 
52 



SERVICE 
RESULTS 
RACKETS 



START 
TIME 



SERVICE COMPLETION ACKNOWLEDGEMENT PACKET 80 
SERVICE RESULTS COMPLETION PACKET 76 
SERVICE RESULTS PACKET 72 
SERVICE RESULTS PACKET 72 
SERVICE RESULTS PACKET 72 
SERVICE RESULTS PACKET 72 
SERVICE RESULTS PACKET 72 
SERVICE RESULTS TRANSMISSION PACKET 68 
SERVICE RESULTS NOTIFICATION PACKET 64 
SERVICE REQUEST PROCESSED BY SERVER COMPUTER 
SERVICE REQUEST ACKNOWLEDGEMENT PACKET 60 
SERVICE REQUEST PACKET(S) 56 



Fig. 4 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 5 of 17 5,838,920 



LU 

CO 




LU 

CC 



UJ CO 

O LU 

> 3 

OC O 

UJ LU 

CO CC 



18 

LU UJ 
CO OC 



IB 

UJ LU 

co cc 



18 

LU LU 

co or 



S£3 

LU LU 
CO CC 



O 



CO 
LU 



CC o 

LU LU 

CO CC 



m 
Ll 



o 

«5 ?c 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 6 of 17 5,838,920 



NO 



READ SERVICE 
PACKET 100 



DISPATCH TO APPROPRIATE 
THREAD DATA SET 104 






READ SUBSEQUENT 


> 


SERVICE PACKETS 112 






f 


no y 


SERVICE COMPLETION 



PACKET? 
116 



YES 



RECORD SERVICE REQUEST 
START AND STOP TIMES 120 



Fig. 6A 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent 



Nov. 17, 1998 Sheet 7 of 17 



INCREMENT SELECTED 
TIME INTERVAL WHILE 
J5TILL IN RANGE?. 
124 



OPEN SERVICE REQUEST FILE 128 



READ SERVICE REQUEST 132 



YES 



END OF 
COMMUNICATIONS 
DATA SET? 
136 



DISPATCH TO APPROPRIATE 
THREAD FOR PROCESSING 144 



Fig. 6B 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent 



Nov. 17, 1998 Sheet 8 of 17 



5,838,920 



1 





RECEIVE SERVICE REQUEST 




1 ► 


ON THREAD 140 


< 1 



RECORD 
TRANSACTION 
MTTERN 160 




ADD SERVICE REQUEST TO 
POSSIBLE TRANSACTION 
PATTERN LIST 150 



INCREMENT 
PATTERN 
OCCURRENCES 
156 



> INITIAUZE PATTERN LIST 164 4 




Fig. 6C 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 9 of 17 5,838,920 



YES 



OPEN SERVICE 
REQUEST RLE 250 






r 


READ SERVICE 




REQUEST 254 


< j 


> 


f 


' END OF \ 
COMMUNICATIONS \ 
DATA SET? / 
\ 256 / 




NO 




r 


DISPATCH TO 
APPROPRIATE 
THREAD FOR 
PROCESSING 258 







Fig 6D 



01/29/2003, EAST Version: 1.03.0002 

i. 



U.S. Patent Nov. 17, 1998 Sheet 10 of 17 



5,838,920 



RECEIVE SERVICE REQUESTS ON THREAD 262 



MATCH SERVICE REQUEST TO 
INITIAL SERVICE REQUEST IN 
RATTERN UST? 
266 



RECEIVE ADDITIONAL SERVICE REQUESTS ON THREAD 270 




RECORD TRANSACTION TIMINGS 282 





Fig.6E 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 11 of 17 5,838,920 




01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 12 of 17 



5,838,920 




01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 13 of 17 



5,838,920 



1 



RECEIVE SERVICE REQUEST ON THREA0 140 < 



TRANSFER 
TRANSACTION 
RATTERN LIST TO 
OTHER THREAD 
DATA SET 204 



RECORD 
TRANSACTION 
RATTERN 160 










YES > 


ADD SERVICE REQUESTTO 
POSSIBLE TRANSACTION 
RATTERN LIST 150 





INCREMENT 
TON 
OCCURRENCES 
156 



INITIALIZE RATTERN LIST 164 




READ NEXT SERVICE REQUEST ()N THREAD 172 [ Fig. 9A 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent 



Nov. 17, 1998 



Sheet 14 of 17 



5,838,920 



TRANSFER SERVICE 
REQUEST STRING 
TO OTHER THREAD 
DATA SET 304 



RECEIVE SERVICE REQUESTS ON THREAD 262 



MATCH SERVICE REQUEST TO 
INmAL SERVICE REQUEST IN 
PATTERN LIST? 
266 

YES 



RECEIVE ADDITIONAL SERVICE REQUESTS ON THREAD 270 



ATCH TO SERVICE 
.REQUEST ON ANOTHER ><" 
.USER THREAD? 
300 




RECORD TRANSACTION TIMINGS 282 



NO /END OF THREADNJES 



Fig. 9B 



DATA SET? 
286 



STOP 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 15 of 17 5,838,920 



214a 210 214b 



Fig. 10 



01/29/2003, EAST Version: 1.03.0002 



U.S. Patent 



Nov. 17, 1998 



Sheet 16 of 17 



5,838,920 





01/29/2003, EAST Version: 1.03.0002 



U.S. Patent Nov. 17, 1998 Sheet 17 of 17 5,838,920 



CM 




L. 



s 

x> 

c 

8 

u> 



E 
F 



S S § R 8 S 

(jiaissod %o») Noiivznun % ndo diuidwoo \bngs 



01/29/2003, EAST Version: 1.03.0002 



5,8: 

l 

METHOD AND APPARATUS FOR 
IDENTIFYING TRANSACTIONS 

This is a continuation of application Ser. No. 08/513,435, 
filed Aug. 10, 1995 now U.S. Pat. No. 5,781,449. 

FIELD OF THE INVENTION 

The present invention is directed generally to the mea- 
surement of response time in computer applications and 
specifically to the use of non-intrusive devices to measure 
response time in multi-tiered computer networks. 

BACKGROUND OF THE INVENTION 

Multi-tiered computer networks are widely used to pro- 
vide one or more users with a wide variety of information 
and computer resources. In multi-tiered computer networks, 
client computers (e.g., users) interact with server computers 
to perform an application which is partitioned into one or 
more transactions. An application is a group of meaningful 
transactions, and a transaction is a unit of meaningful work 
as perceived by the user. A transaction is typically a collec- 
tion of service requests, with the service request typically 
being a collection of service packets. A service packet is 
simply an item of information, or a message, communicated 
between computers. In the course of performing a 
transaction, the client computer may request one or more of 
the server computers to transfer service packets containing 
data to the client computer or provide service packets 
containing data to the server computers) to permit the 
server computers) to process the request. The server com- 
puters can in turn request the services of other server 
computers in connection with the data transfer request from 
the client computer. 

Performance monitoring of the network is important to 
ascertain periods of significant transaction user delays and 
user productivity. Performance monitoring generally seeks 
to measure the response time for a transaction or application. 
The response time is the time required for the servers and 
network to perform the transaction or application. Statistical 
analysis can be performed on the response times to facilitate 
analysis of servers and network performance. 

Two methods are commonly used to monitor network 
performance and provide response times. Intrusive/invasive 
monitoring techniques alter the software code on the client 
computer to include a marker command. The marker com- 
mands inform a listening device of transmission of the initial 
service request packet to initiate timing measurement and 
receipt of the final results or acknowledgement packet to 
cease timing measurement. Non-intrusive/non-invasive 
monitoring techniques, in contrast, typically do not alter the 
software code. Rather, a probe is inserted into a communi- 
cation line between the client and server computers to 
monitor the delays between transmission of individual pack- 
ets between the client and server computers to provide a 
rough estimate of response time. 

Intrusive/invasive and non-intrusive/non-invasive tech- 
niques each have a number of drawbacks. In the case of 
intrusive/invasive techniques, though the transaction 
response time is provided, few multi-tiered applications are 
written with embedded marker commands in the code. Even 
if the applications were to have embedded marker 
commands, technical problems, can arise due to and con- 
solidation of application-embedded response time statistics 
to a central location, especially for mobile user computers. 
In the case of non-intrusive/non-invasive techniques, it is 
only possible to determine the rate of information transmis- 
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sion between the computers for individual packets. Such 
techniques are typically unable to determine the response 
time for a transaction or application. Neither intrusive/ 
invasive nor non-intrusive/non-invasive monitoring tech- 
5 niques are able to match, especially in multi-tiered networks, 
individual packets with the corresponding transaction to 
compute a response time for the transaction or related 
application. As noted above, each of the server computers 
performing an application can process a series of individual 
10 service requests pertaining to a variety of different user 
transactions. Existing monitoring techniques are unable to 
match the service packets in the various service requests to 
a specific transaction. 
There is a need for an apparatus and method for measur- 
es ing the response time for a transaction or an application, 
especially in multi-tiered computer networks. There is a 
related need for an apparatus and method for measuring the 
response time for a transaction or an application using 
non-intrusive/non-invasive techniques. 
20 There is a need for an apparatus and method for measur- 
ing the response time for a transaction or an application that 
is able to match individual service packets with the corre- 
sponding transaction or application. 

25 SUMMARY OF THE INVENTION 

The present invention addresses these and other needs by 
providing in one aspect a method for identifying a transac- 
tion corresponding to a plurality of service packets commu- 

3o nicated between a source node and a destination node. The 
method includes the steps; (i) providing a communications 
data set including a plurality of service packets and infor- 
mation relating to the order in which the service packets are 
communicated on a communications line between the source 
and destination nodes and (ii) comparing the communica- 

3 tions data set against a pattern characterization data set to 
determine whether at least a portion of the plurality of 
service packets are part of the transaction. The pattern 
characterization data set includes information relating to a 

^ predetermined ordering of service packets that comprise the 
transaction. The method is amenable to non-intrusive/non- 
invasive measuring techniques and can provide near real- 
time response time information, even for multi-tiered com- 
puter networks. 

45 The invention is based in part upon the recognition that 
the service packets communicated along the communica- 
tions line constitute patterns of service requests that occur 
repeatedly in an operational environment. These service 
request patterns correspond to different transaction types. It 

5Q has been discovered that these service request patterns can 
be determined using signal processing techniques. Once 
identified, the start and stop times for the pattern can be 
determined to provide a response time for the transaction. 
A probe can be used to read the packets on a real-time 

55 basis from the communications line with the packets being 
recorded along with a received time (e.g., the time at which 
the packet was read by the probe) in the communications 
data set. 

The packets can be filtered based on a node address and/or 
60 port number. In a preferred embodiment, the service packets 
correspond to a plurality of threads and the packets are 
sorted by thread. 

The service request packets can be identified by their 
contents and destination. The service result packets can then 
65 be correlated with the corresponding service request pack- 
ets. The start and stop times for the service request can then 
be determined. 
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After identification of the service requests corresponding 
to the transaction, tbe response time for the transaction can 
be determined using the various start and stop times for the 
service requests. 

In another aspect of the present invention, a non-intrusive 
system is provided for identifying a transaction comprising 
a plurality of service packets communicated between source 
and destination nodes. The system includes: (i) a device for 
recording a plurality of service packets communicated on 
the communications line and (ii) a device, in communication 
with the recording device, for identifying a transaction that 
includes at least a portion of the plurality of packets. 

In yet another aspect, the present invention provides a 
method for identifying a transaction comprising a plurality 
of service packets communicated between source and des- 
tination nodes that includes the steps: (i) providing a com- 
munications data set including (a) a plurality of service 
packets corresponding to a plurality of service requests and 
(b) the start and stop times for each service request and (ii) 
comparing the time interval between the stop of a first 
service request and the start of a second service request 
against a predetermined value for the time interval to 
identify a sequence of service requests that comprise a 
transaction. 

The comparing step can be performed in several iterations 
where the time interval is varied to select an optimal 
predetermined value for the time interval between service 
requests to yield a substantially optimal listing of service 
request sequences as a possible transaction. The resultant 
number of transaction service request patterns are then used 
to determine an optimal value for the predetermined time 
interval. For a range of time intervals the number of trans- 
action service request patterns remains constant. The opti- 
mal value for the predetermined time interval is the midpoint 
of this range of values. By way of example, after identifying 
a service request sequence(s) using the predetermined 
values, the method can further include selecting a second 
predetermined value, comparing the time intervals, between 
service requests, against the second predetermined value to 
identify a second sequence(s) of service requests corre- 
sponding to a second transaction(s), and recording the 
second sequence(s) of service requests and the number of 
occurrences of each of the second sequence(s) in a second 
data set. The method next selecting a third predetermined 
value (which is the optimal predetermined value) based on 
the relationship between (i) the number of the sequence(s) of 
service requests and the predetermined value and (ii) the 
number of the second sequence(s) of service requests and 
the second predetermined value. The method then comprises 
as before the time interval between service requests against 
the third predetermined value for the time interval to identify 
a third sequencers) of service requests corresponding to a 
third transaction(s). The service request sequence for the 
third transaction is deemed to be the optimal sequence. The 
third sequence is then compared against the communications 
data set to determine whether at least a portion of the 
plurality of service requests correspond to one or more 
transactions). 

The method produces the pattern characterization data set 
referred to above. The pattern characterization data set lists 
a plurality of service request sequences for comparison 
against the service requests from the comparing step. This 
additional comparison step is to determine if the service 
requests as ordered by time are contained in the pattern 
characterization data set. 

In a final aspect, the present invention includes a non- 
intrusive system for determining transaction level activity 
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between a source and destination node. The system includes: 
(i) a device for recording a plurality of service packets 
communicated on a communications line between source 
and destination nodes and (ii) a device for determining the 
5 number of transactions in communication with the recording 
device. The service packets relate to a number of transac- 
tions and the recording device provides the communications 
data set. 

In one embodiment, the determining device is a device for 
10 comparing the time interval between the stop time of a first 
service request and the start time of a second service request 
against a predetermined value for the time interval to 
identify a sequence of service requests in the communica- 
tions data set that together comprise a transaction. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 depicts an embodiment of the present invention 
connected to a computer network; 
20 FIG. 2 depicts another embodiment of the present inven- 
tion connected to a multi-tiered computer network; 

FIG. 3 depicts a service packet; 

FIG. 4 depicts an example of the service packets in a 
service request; 

25 FIG. 5 depicts the response time for a transaction involv- 
ing a number of service requests; 

FIGS. 6A-E depict a first embodiment of a method 
according to the present invention for determining response 

30 time; 

FIG. 7 depicts the interactions of service requests in the 
pattern finding and matching steps; 

FIG. 8 is a plot of the predetermined time value against 
the number of transactions discovered; 
35 FIGS. 9A-B depict a second embodiment of a method 
according to the present invention for determining response 
time; 

FIGS. 10-11 depict the interactions of service requests in 
the pattern finding and matching steps; and 

FIG. 12 is a graphical presentation of CPU utilization 
versus response time for a transaction. 

DETAILED DESCRIPTION 

45 The present invention is directed to a method and appa- 
ratus for measuring response times for a transaction or an 
application using non-intrusive/non-invasive techniques. As 
noted above, non-intrusive/noa-invasive monitoring tech- 
niques do not interrupt the software code to measure 

50 response time. Rather, such techniques monitor the network 
communications between the client computer and the vari- 
ous server computers. Unlike existing performance moni- 
toring methods, the method of the present invention matches 
selected service packets and associated start and stop time 

55 information for the service packets with the corresponding 
transaction or application. After the matching step, the 
method provides response times for the transaction or appli- 
cation. The present inventic " ,g "^jf.fi' 1 n ^ r mW fn r \^ rfnr - 
mance ^m onitoring but also for billing and monitor ing of 

60 serv ice level agreement compliance. 

The Apparatus Configuration 

The apparatus configuration according to the present 
invention is depicted in FIGS. I and 2. Referring to FIG. 1, 
65 the simplest single network segment is depicted. In the 
network, a recording device or probe 20 is connected to a 
communication line or busline 24 between a client computer 
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28 and a server computer 32. The recording device 20 selects packet 56 and the received time for the service completion 

service packets transmitted along the communication line 24 acknowledgment packet 80. 

and provides the service packet and the lime at which the To further illustrate the response time for a transaction, an 

service packet was received by the recording device 20 to example of a transaction involving numerous service 

the monitoring computer 36 for analysis. FIG. 2 depicts a 5 requests will be described with reference to FIGS. 2 and 5. 

more complex multi-tiered architecture with multiple net- a type "A" transaction executed on the client computer 28 

work segments. Recording devices 20 a,b are connected via makes service request 1 of server computer 32fl and service 

a communications device 22, such as a modem, to the request 2 of server computer 326. To complete service 

communication lines 2$a,b between the network segments request 1, server computer 32b makes service request 3 of 

26a,/>. The network segments include client computer 28 1Q server computer 32c. When service request 1 is completed, 

and server computers 32a,b c,d and the communication lines the type "A" transaction makes service requests 4 and 5 of 

24 a, b. As can be seen from these figures, the present server computer 32rf and service type 6 (e.g., service request 

invention does not measure response time within the various 6) of server computer 32c. The pattern of service requests to 

client and server computers as in intrusive/invasive moni- ^ various server computers identifies the transaction as a 

toring techniques, but measures response time by monitor- type " A " transaction. The response time for the type "A" 

ing the network communications on the communications 15 transaction is measured from the start time of service 

line between the client computer and the various server requests 1 and 2 to the stop time of service request 5. Thus, 

computers. ^ c transaction response time is simply a collection of 

<-pt . . , . Ct , , individual service request response times. 

The number and locations of the recording device(s) 20 in ~i i~ 

a multi-tiered computer network depend upon the applica- 2 q T° e Filtering of Service Packets 

tion. Typically, a recording device 20 will be located on any FIGS. 6A-E provide a flow schematic depicting a first 

portion of the communication line 24 that is between the embodiment of a performance monitoring method according 

points of access of the drivers of client or server computers to the present invention. The method collects selected ser- 

to the communications line 24. In this manner, all of the vice packets from the recording device(s) and filters the 

service packets communicated on the communications line 25 selected service packets to form a communications data set. 

24 will be read by a recording device 20 and an accurate The network communications are filtered to yield only those 

determination of the response time for a transaction or service packets relevant to the application(s) of interest. As 

^ application involving multiple client and/or server comput- will be appreciated, it is possible that multiple applications 

ers can be made. ■ — . on the same client computer request the same type of 

The text of a typical service packet communicated 30 services from a specific server computer. It is also possible 

between computers in a multi- tiered computer network is that a service provider may migrate from one server com- 

depicted in FIG. 3. As can be seen from FIG. 3, a service puter to another server computer of the same type. 

packet 38 typically includes a node address 40, which The first embodiment is based on the assumption that the 

identifies the source and destination of the service packet, a packets of a given transaction are located on only one thread. 

port number 44, and additional information 48. Depending 35 A given thread can, however, have packets from more than 

upon the application, the service packet can have additional one transaction. A second embodiment of the present inven- 

information, such as a database request, file system request tion is discussed below for an application in which a given 

and object broker request. transaction occurs on more than one thread. 

There are generally two types of service packets, namely As used herein, a thread is a specific identifiable connec- 

service request and service results packets. Service request 40 tion or session between a ser vice requester node and a 

packets request a server computer to perform a specific service provider node. A thread is preferably identifi ed such 

action. Service results packets are service packets generated th at it can have only one service request on it at a given pomt 

in response to the service request packet. Service results in timq ) As wm pe appreciated, jn some applications th e ^ „ 

packets can contain a variety of information including the node address is not an adequate identifier of each thread 3^-^ 



packets can contain a variety of information including the n ode address is not an adeq uate identifier 01 

information requested by the service request packet. 45 b ecausejher e can be multipl e sessions tor a given node 

To illustrate the use of two types of service packets in a addressTIn such cases, the connection or session identifica - 

s ervice reques t, an example of a ser vice request involving tfcn miorwaliuil lb> used tu lUrther 1 ldermTy the threa d to 

numerous service packets is depictecfin FIG. 4. A typical which the service packet is to be dispatched . A thread can be 

service request 52 begins with the service request packet 56 either a user thread, wnich is a thread that is uniquely 

(which can be multiple service packets) issued by, for 50 identifiable to a specificjcji ent computer, or a shared thread, 

example, a client computer to a server computer. The server which is a thread shared among muluple user requests, 

computer then transmits a service request acknowledgement Referring to FIG. 6A, one or more recording devices 20 

packet 60 to the client computer and begins processing the first read in command box 100 one or more service packets 

request. When the server computer has completed process- from the communications line 24. Based on the node address 

ing the service request, the server computer sends a service 55 or other threa d identificat ion info rmation^ a recording device 

results notification packet 64 to the client computer that the 20*3etermmes if the "service packet pertains to the client 

server computer is ready to send the service request's data computers) and/or server computers) (e.g., threads) of 

to the client computer. The client computer then transmits a interest. If so, the service packet is recorded and the time the 

service results transmission packet 68 requesting transmis- service Racket was read by the recording device 20 (e.g., 

sion of the data. The service computer commences trans- 60 received time); otherwise, no record is made of the service 

mitting service results packets 72. The service results packet. If one were interested in a particular subset of 

completion packet 76 notifies the client computer that the service requests, the recording device 20 could filter based 

final service results packet has been transmitted, and the not only on the node address or other thread identification 

service results acknowledgement packet 80 notifies the information but also on the port number. The port number is 

server computer that the information has been received. The 65 useful for filtering if the application is configured such that 

response time to complete the service request is the differ- there is only one service request on a port at a given point 

ence between the received time for the service request in time. 
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In a command box 104, the service packet is recorded in 
a communications data set by being dispatched to an appro- 
priate thread data set. The communications data set contains 
the service packets read by all of the recording devices 
organized by the thread. There is a thread data set for each 
thread. In most applications, a plurality of thread data sets in 
the communications data set are active at any point in time. 

The service packet is next examined in decision box 108 
to determine if it is a service requr.-J parrlfgt Th is is 
ac comp li shed by searching in the text of the service packet 
for a key word(s) and/or symbol(s) unique to a service 
request packet; that is, the words and/or symbol&^are not 
used in service results packets. The words and/or symbols 
used in the search can be specific to a given transaction 
and/or application. 

If the service packet is an initial ser vice request pac ket, 
th e_subseque^t y-rvin r. packets are read in command box 112 
to identify in decision box 116 the service completion 
packet. The service completion packet islhe final service 
results packet in a service request. As noted above, there will 
only be one set of service packets for a specific service 
request that is serial on the thread at a particular moment in 
time. The set of service packets for a given service request 
comprise a service data subset. Accordingly, the matching of 
the service request packet with the corresponding service 
results packets is a relatively straightforward process. 

There are two methods to identify the service completion 
packet. In one method, the text in each service results packet 
is searched for key word(s) and/or symbol(s) only associated 
with one or more of the service results packets. In the other 
method, the service packet having the latest received time is 
assumed to be the service completion packet. In other words, 
the last service packet on the thread before the immediately 
succeeding service request packet is assu med to the service 
c ompletion pack et. The last packet on the thread can be sent 
by either the client or server computer. Which of the two 
methods is preferred in a specific case depends upon the 
application. 

After the service request and service completion packets 
are identified in decision box 116, the start and stop times for 
the service request are recorded in command box 120 in th e 
communications d ata set along with the thread identificati on 
mformation aH6""a ser vice request identifier a nd possibly 
recording device location. 'liie start time is the received time 
for the service request packet, and the stop time is the 
received time for the service completion packet. The service 
r equest id_gn nfW can be anv suit able means for identifying 
tE e type of service to which the service request pertai na^By 
way of example, the service request identifie r can he a 
command ft r n p^ fl ™ -Hereof es pecially in rj a^aprocessinp 
appl ication*^ The communications data set can include other 
in formation including the location of the recording device 
20 on the communications line 24, network type and other 
recording information. 

The preceding steps are repeated on a packet-by-packet 
basis for the service packets communicated along a section 
of the communications line 24 over a selected time period. 
The time period can be discrete or continuous. In either case, 
the communications data set is, after an appropriate time 
interval, subjected to the steps discussed below to identify 
response time. 

For service packets having encrypted or compressed data, 
it is typically necessary to know or determine the compres- 
sion algorithm before applying the filtering steps. Additional 
steps may therefore be required to unencrypt or uncompress 
the packets. 



18,920 

8 

The Transaction Pattern Finding Steps 

In a series of transaction pattern finding steps discussed in 
detail below, the monitoring computer 36 analyzes the 
communications data set to identify a sequence of service 

5 requests that together comprise a possible transaction pat- 
tern. Generally, the monitoring computer 36 identifies the 
service request sequence by comparing the time interval 
between the stop time of a first service request and the start 
time of a succeeding service request against a predetermined 

10 value for the time interval. If the time interval is less than or 
equal to the predetermined value, the service requests are 
deemed to be part of the same transaction and if the time 
interval is more than the predetermined value, the service 
requests are deemed to be part of separate transactions. 

15 Accordingly, the selected time interval is selected based on 
the maximum projected time interval between adjacent 
service requests for the two service requests to be considered 
part of the same transaction. 

2Q Referring to FIG. 6B to initiate the transaction pattern 
finding steps, a selected time interval can be increased or 
decreased by a selected time increment in decision box 124. 
If the selected time interval is at the upper or lower limit of 
the desired range of time interval values, processing is 

25 terminated. The selected time interval and incremental 
increases or decreases thereof are discussed in greater detail 
below. As will be appreciated, a smaller selected time 
interval yields a smaller number of possible transaction 
patterns than a larger selected time interval. 

3 q After selection of the appropriate selected time interval, 
the monitoring computer 36 in command box 128 opens for 
all of the selected time intervals a service request file, to 
contain information generated in the succeeding steps. As 
discussed below, the service request file will contain the 

35 service requests sorted by thread and selected time interval. 
Returning to FIG. 6B, the monitoring computer next reads 
in command box 132 a service request from the communi- 
cations data set and, in decision box 136, determines if all of 
the service requests in the communications data set have 

40 been read. If so, the monitoring computer goes to decision 
box 124. If not, the monitoring computer dispatches the 
service request in command box 144 to the appropriate 
thread to form a thread data set with one thread data set 
existing for each thread. As the various service requests are 

45 read from the communications data set and dispatched to the 
thread data sets for each selected time interval, a collection 
of service requests can form in each thread data set. The 
service requests in each thread data subset are ordered by 
their respective start and stop times. Thus, as noted above, 

5Q each of the service requests in the collection is separated 
from an adjacent service request by a time interval. Com- 
mand boxes 132, 144 are repeated until all of the service 
requests in the communications data set are sorted by thread 
for each selected time interval. 

55 After the computer in decision box 124 Determines the all 
selected time intervals have been analyzed, the computer 
proceeds to command box 140. In command box 140, the 
service requests from the communications data set are all 
received into the various thread data sets. As will be 

60 appreciated, the ensuing steps in FIG. 6C are performed for 
each selected time interval in the service request file. 

The service requests in each thread data set are next 
examined in decision box 148 to determine if the various 
service requests are local to another service request in the 

65 thread data set. A service request is local to another service 
request if the time interval between the service requests is no 
more than the selected time interval. If the service requests 
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are local to one another, the service requests are considered 
to be components of the same transaction. If the service 
requests arc not local to one another, the service requests arc 
considered to be components of different or separate trans- 
actions. 

Referring to FIG. 7, a string or sequence of service 
requests of the type generated in each thread data set in the 
service request file is illustrated. The string or sequence of 
service requests can refer either to a collection of service 
requests that are local with respect to at least one other 
service request in the sequence or to a single service request 
that is not local to another service request. As will be 
appreciated, a possible transaction pattern can have one or 
more service requests. Thus, in FIG. 7, the time intervals 
ATa-d separating the service requests I56a-e are no more 
than the selected time interval. 

If a service request in a thread data set is local to another 
service request in the thread data set, the service requests in 
command box 150 are combined and added as a new 
possible transaction pattern to a possible transaction list in a 
pattern characterization data set in the service request file. 
As will be appreciated, the service request can be local to 
another service request that is either discrete or part of a 
string or sequence of a number of service requests. In this 
manner, a sequence of service requests corresponding to a 
given possible transaction pattern is progressively expanded 
to include additional service requests. 

The pattern characterization data set can include a variety 
of information, including the various selected time intervals 
and the corresponding thread data sets, with each thread data 
set including variables for identification of the thread, the 
various service requests associated with the thread organized 
in service request sequences, and the number of occurrences 
of each service request sequence. This list of service request 
sequences is hereinafter referred to as the possible transac- 
tion pattern list. 

The pattern characterization data set can also include 
other information depending upon the application. By way 
of example, the pattern characterization data set can include 
the transaction type associated with each sequence of service 
requests. The transaction type can be based upon the identity 
of one or more of the service requests in the service request 
sequence corresponding to the transaction (e.g., the service 
request identifier). 

The generation of the pattern characterization data set is 
initiated in command box 140 by receiving a service request 
from a thread data set in the record file. If the subject service 
request is not local to a previous service request in the thread 
data set, the service request sequence that immediately 
precedes in time the subject service request, if any, is 
compared in decision box 152 to previously identified 
patterns in all of the thread data sets for the related selected 
time interval in the pattern characterization data set to 
determine if the pattern has previously been recorded 
(discovered) for the selected time interval. 

If the preceding service request sequence is not a new 
possible transaction pattern, the number of occurrences of 
the possible transaction pattern for the selected time interval 
is incremented in command box 156. More specifically, the 
recorded number of occurrences of the possible transaction 
pattern having the same sequence of service requests is 
increased by one. 

Returning to decision box 152, if the service request 
sequence preceding the subject service request is a new 
possible transaction pattern for the selected time interval, the 
monitoring computer in command box 160 records the 
service request sequence on the possible transaction pattern 
fist. 
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After command boxes 156, 160, the possible transaction 
pattern list is initialized in command box 164 to begin a new 
service request string for the selected time interval begin- 
ning with the subject service request. Based on the fact that 

5 the subject service request is not local to the immediately 
preceding service request, the program assumes that the 
service request sequence of which the immediately preced- 
ing service request is a part is completed. Because the 
service request is not local to a prior service request, the 

10 monitoring computer assumes that the service request is a 
part of a new service request sequence. 

After command box 164 is completed, the monitoring 
computer determines in decision box 168 if the end of the 
thread data set(s) in the record file has been reached for all 

15 of the service requests in all of the selected time intervals. 
If so, the process is terminated. If not, the computer proceeds 
to command box 172 and receives another service request 
from a thread data set in the record file. 
After command boxes 150 and 172 are completed, the 

20 monitoring computer returns to command box 140 and the 
preceding steps are repeated until all service requests in the 
record file have been read and processed. 

In a communications data set having a plurality of threads, 
the monitoring computer applies the transaction pattern 

25 finding steps in parallel to service requests from different 
threads. Thus, the service requests in a plurality of different 
thread data sets are analyzed simultaneously. Accordingly, at 
any point in time, a plurality of thread data sets can be active. 

30 In a preferred embodiment, an optimal value for the 
selected time interval is selected by first selecting a series of 
selected time intervals for decision box 124. As noted above, 
the predetermined values can be selected using a predeter- 
mined increment in decision box 124. The values used for 

JS the selected time intervals are usually subsecond intervals 
ranging, for example, from about 50 to about 500 millisec- 
onds. 

Referring to FIG. 8, after the performance of the above- 
noted command and decision boxes with various selected 

4Q time intervals, the numbers of possible transaction patterns 
from the pattern characterization data set (e.g., vertical axis) 
are plotted against the corresponding selected time intervals 
(e.g., horizontal axis). An optimal value for the selected time 
interval is selected in the central portion of the plateau 176 

4 5 on the curve 180. Using the optimal value in decision box 
124, the transaction pattern finding steps are repeated to 
yield a second pattern characterization data set. The trans- 
action patterns in the second pattern characterization data set 
are believed to be the substantially optimal listing of trans- 

50 action patterns for the various service requests in the record 
file. 

Referring to FIG. 9 A, the second embodiment of the 
present invention is depicted. FIG. 9 A replaces FIG. 6C and 
otherwise has the same steps as the first embodiment in 

55 FIGS. 6A and B. FIG. 6C is substantially identical to FIG. 
9A except for decision box 200 and command box 204. As 
noted above, the second embodiment, unlike the first 
embodiment, is applicable to applications and/or transac- 
tions that have more than one thread for a transaction. 

60 There are generally three situations where an application 
or transaction has more than one thread per transaction. In 
one situation, a specific thread will perform only one service 
request type. After the service request type is performed, the 
application or transaction utilizes other threads. In another 

65 case, the application or transaction is performed on a number 
of user threads in sequence. For example, a number of 
service requests are performed on one user thread and a 
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number of later service requests are performed on another In command box 254, a service request is read from the 

user thread. In this manner, the application or transaction can communications data set and dispatched in command box 

move back and forth among user threads. In the last case, 258 to the appropriate thread to form a thread data set in the 

two or more client computers use a shared thread to perform service record file with one thread data set existing for each 

service requests. 5 thread. 

To address the use of more than one thread for a In decision box 256, the monitoring computer determines 

transaction, decision box 200, in response to a negative if ihe last service request in the communications data set has 

response to decision box 148, determines if the service been fead ]f ^ lfac monitoring computer proceeds to 

request sequence that immediately precedes in tune the comraand ^ 2 62. If not, the monitoring computer returns 

subject service request is local to a service request m other 10 to command ^ 254. Io this manocr , aU service requests in 

thread data sets. thc communications data set are sorted by thread data set 

Referring to FIGS. 7 and 10-11, the three possible results before the steps of FIG 6E ~~ * — 

in decision box 200 of comparing the service requests in Ref — ^ tQ na 6£ ^ ( nces ^ 

dtfferent thread data sets are illustrated In FIG. 7, a serv.ee ead) thfcad da(a wbicb are ordered bascd Qn ^ ^ 

request 15W in one thread data set a local to the immedi- l5 m ains , the ttenl characterization 

ately preceding service request sequence (e.g., service da(s ^ (o determijK whether a , , easl , rtion of the xrvice 

requests 15fa-c) in another thread data set because a time , nces are t of a ible lransaction pattera . 

interval ATc between the service request 156c and a service , . . r , r L . . . . . 1 , 

request 156rf in the service request sequence is no more than ,n declslon 2<6 > lhc matchm 8 P rocess * " u ' atcd h * 

the selected time interval. In FIG. 10, a service request 210 20 comparing a subject service request ui a thread data set 

in one thread data set is not local to the service request a S amst ,he u m . lt,a ' ^""J u « te V r ! ous transact '° a 

sequence (e.g., service requests 21*,-*,) in another thread P attems ° b,amed frorD aU of lh , e f * read data x * m ' he 

data set because the service request overlaps the service P attera characterization data set If the service request does 

i .u . • „ + - _ not match any of the mitial service requests in the transac- 

request sequence. In other words, the service request is not . • , * « L 

li. *u „ ~ « , r ™,.„t tion patterns obtained for all of the threads, the monitoring 

local to the service request sequence if the service request ?s , . • , . 

, . , c „ , _ computer receives another service request in command box 

was initiated or incomplete before the completion or , B ... , „^ . ^ , , r , 

. ... • t . , Jr ■ . ■ 5 262 and the decision box 266 is repeated. If the service 

initiation, respectively, of a service request in the service . . . . , ^ , 

r r- j- « . -~ . .■ request matches an lmual service request, another service 

request sequence. For a discrete service request or service M . t . . \ . . 

. . . . A , j i , M4 •« request from the thread data set is received in command box 

request sequence to be copied to another thread data set, it J* 

is thus critical that the service request or service request 30 

sequence does not overlap a portion of the service request la decision box 274, the monitoring computer determines 
sequence on the other thread data set (e.g., service requests whether swice request received in command box 270 is 
214<i-6). In FIG. 11, a service request 218 in one thread data local 10 me initial sen** request identified in decision box 
set is not local to the service request sequence (e.g., service 266 - If ^ the monitoring computer returns to command 
requests 222a-b) in another thread data set because the time 35 DOX 262 and repeats the steps described above with another 
intervals ATe between the service request 218 and the request. If so, the monitoring computer in decision 
service requests 122b in the service request sequence are 0031 278 determines based on the transaction pattern in the 
greater than the selected time interval. P attera characterization data set if the service request read in 
A service request or service request sequence can be command box 270 is the final service request in the trans- 
transferred to one or more thread data sets in series or 40 actlon P attern * 

parallel. For example, the service request or service request To determine if the service request is the final service 

sequence in one thread data set can be sequentially trans- request in a probable transaction, the monitoring computer 

ferred to a second thread data set and to a third thread data relies upon the sequence of service requests in the transac- 

set (e.g., series) or to two or more other thread data sets at uor i patterns in the thread data set. If the service request is 

substantially the same lime (e.g., parallel). 45 not lhe 60111 semsx request in the probable transaction, the 

If the service request sequence is local to a service request monitoring computer returns to command box 270. If the 

in another thread, the service request sequence in command Tt ^ s{ 15 the final xrvicc re <£ est > me ™nitonng 

box 204 is transferred to the possible transaction pattern list computer records^ command box 282 the start and stop 

in the other thread data set. After completing command box Ume for P^ abic transacUoD P attcrn and P«»eeds to 

204, the monitoring computer returns to command box 140. 50 decision box 286. 

If the service request sequence is not local to a service In dccision box ^ • '* il » determined that if all of the 

request in another thread, the monitoring computer contin- rcc ^ csls m thc thread data ? avc bccn charac " 

ues to decision box 152. tenzed into service request sequences, the program is ter- 
minated. Otherwise, the computer returns to command box 

The Transaction Pattern Matching Steps 55 2 62. Preferably, the preceding steps are performed in par- 

In the transaction pattern matching steps, the communi- allel for aU of the t hread dat a sets, 

cations data set is compared against the pattern character- The preceding steps yielcTa pattern analysis data set 

ization data set from the transaction pattern finding steps to containing the various service request "sequences that 

determine whether at least a portion of the plurality of together comprise the^various^ transactions, the^response 

service packets are part of one or more transactions. The go UXB^Jor_?ach transa ction, and thTlbca tion 'oT Selic^ ding 

start and stop times of the service requests corresponding to device., .The pattern Tnalysis da ta set ganl pclude addiiio nai 

the service packets can then be used to provide a response ipfoi^aiioar-sucb^ ^user identification fcnd thrgari idp.ntifi - 

time for the transaction and/or application. cajion^ ' " == ^ 

Referring to FIG. 6D, to initiate the transaction pattern Referring to FIG. 9B, the second embodiment of the 

matching steps, a service request file is opened in command 65 present invention is depicted. FIG. 9B replaces FIG. 6E and 

box 250 to receive service requests read from the commu- otherwise has the same steps as the first embodiment in FIG. 

nications data set. 6D. FIG. 9B is substantially identical to FIG. 6E except for 
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decision box 300 and command box 304. To address the use 
of more than one thread for a transaction, decision box 300, 
in response to a negative response to decision box 274, 
determines if the service request sequence is local to a 
service request in another thread data set. If the service 
request sequence is local to a service request in one or more 
other thread data set(s), the service request sequence in 
command box 304 is transferred to the other thread data 
set(s). After completing command box 304, the monitoring 
computer returns to command box 262. If the service request 
sequence is not local to a service request in another thread 
data set, the monitoring computer continues to decision box 
278. 

After completion of the preceding steps of the first or 
second embodiments, the information in the pattern analysis 
data set can be used to generate performance statistics 
and transact ion counts. For example, the resulting transac- 
tion response data can be aggregated into a fixed time 
interval, such as five minutes, and response time statistics, 
such as maximum, mean, standard deviation, and 70th, 80th 
and 90th percentiles, calculated by transaction type. The 
discrete transaction response time information can be used 
to analyze response times by service request breakdown 
within the transaction or by user class and other variants. An 
example of an analysis report for a transaction is shown in 
FIG. 12. The data can also be used to determine transaction 
counts performed over a discrete time period. 

The pattern characterization data set can include transac- 
tion patterns determined by a process other than the trans- 
action pattern finding steps. By way of example, a test can 
be performed for the transactions of interest to identify the 
service request sequences generated during the transactions. 
This method may be incomplete in some cases because a 
transaction can generate a multiplicity of service request 
sequences based on the particular responses selected by the 
user. 

The transaction pattern finding and matching steps can be 
modified to discard incomplete service request sequences. 
Such service request sequences are typically the result of 
initiating the selected time period for recording of service 
packets after a transaction has already started or ending the 
selected time period before a transaction has ended. To 
eliminate incomplete service request sequences, any service 
request sequence in a thread data set that is not separated 
from a preceding or succeeding service request by a time 
interval that is more than the selected time interval is 
discarded. This modification assumes, of course, that any 
service requests separated by a time interval that is more 
than the selected time interval are not part of the same 
service request sequence. 

While various embodiments of the present invention have 
been described in detail, it is apparent that modifications and 
adaptations of those embodiments will occur to those skilled 
in the art. It is to be expressly understood, however, that such 
modifications and adaptations are within the scope of the 
present invention, as set forth in the appended claims. 

What is claimed is: 

1. A method for analyzing the transmission of a plurality 
of service packets along a communication line, comprising: 

providing a communications data set including informa- 
tion relating an ordering of a collection of service 
packets, the service- packets being communicated along 
the communication line, wherein the information 
includes start and stop times for each of a plurality of 
service requests that include the service packets; 

selecting a first selected time interval; 
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comparing a time interval between the stop time of a first 
service request and the start time of a second service 
request wiih the first selected time interval to identify 
a first sequence of the service requests included in a 
5 first transaction; 

selecting a second time interval different from the first 
selected time interval; and 

comparing the time interval with the second selected time 
interval to identify a second sequence of the service 
10 requests included in a second transaction. 

2. The method of claim 1, wherein, when the time interval 
is no more than the first selected time interval, the first and 
second service requests are considered to be a part of the first 
transaction and, when the rime interval is no more than the 

15 second selected time interval, the first and second service 
requests are considered to be a part of the second transac- 
tion. 

3. The method of claim 1, further comprising: 

2Q recording each of a first sequence and a second sequence 
of service requests and a number of occurrences of each 
of the first and second sequences. 

4. The method of claim 3 further comprising: 
selecting a third selected time interval based on the 

25 relationship between (i) the number of occurrences of 
said first sequence of service requests and said first 
selected time interval and (ii) the number of occur- 
rences said second sequence of service requests and the 
second time interval. 

30 5. The method of claim 4, further comprising: 

comparing said time interval against the third selected 
time interval to identify a third sequence of service 
requests corresponding to a third transaction. 

6. The method of claim 5, further comprising: 

35 computing a response time for the third transaction based, 
on the third selected time interval. 

7. The method of claim 1, further comprising after the. 
comparing step: 

forming a pattern characterization data set using data . 
40 related to a grouping of at least some of the plurality of 
service packets corresponding to an occurrence of at 
least one of the first and second transactions. 

8. The method of claim 1, further comprising: 

45 comparing the communications data set with a pattern 
characterization data set to determine whether at least 
some of the collection of said plurality of service 
packets correspond to an occurrence of at least one of 
the first and second transactions. 

5Q 9. A method for analyzing the transmission of a plurality 
of service packets along a communication line, comprising: 
providing a communications data set including informa- 
tion relating an ordering of a collection of service 
packets, the service packets being communicated along 

55 the communication line and corresponding to a plural- 
ity of service requests, wherein the information 
includes a time interval between pairs of adjacent 
service requests; 
selecting a first selected time interval; 

60 comparing the time intervals between adjacent pairs of 
service requests with the first selected time interval to 
identify a first sequence of the service requests included 
in a first transaction type wherein, when the time 
interval between a selected pair of adjacent service 

65 requests is no more than the first selected time interval, 
the selected pair of service requests is considered to be 
a part of the first sequence; 
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selecting a second time selected interval; and 
comparing the time intervals between adjacent pairs of 
service requests with the second selected time interval 
to identify a second sequence of the service requests 
included in a second transaction type wherein, when 5 
the time interval between a selected pair of adjacent 
service requests is no more than the second selected 
time interval, the selected pair of service requests is 
considered to be a part of the second sequence. 

10. The method of claim 9, further comprising: 10 
forming a pattern characterization set based on the first 

and second sequences. 

11. The method of claim 9, further comprising: 
recording each of the first and second sequences of 15 

service requests and a total number of occurrences of 
service requests in each of the first and second 
sequences. 

12. The method of claim 9, further comprising: 
selecting a third selected time interval based on the 2 o 

relationship between (i) a number of occurrences of 
said first sequence of service requests and said first 
selected time interval and (ii) a number of occurrences 
of each of the second sequence of service requests and 
the second time interval. 2 5 

13. The method of claim 12, further comprising: 
comparing said time intervals against the third selected 

time interval to identify a third sequence of service 
requests corresponding to a third transaction type. 

14. The method of claim 13, further comprising: 30 
computing a response time for a transaction. 

15. The method of claim 9, further comprising: 
forming a pattern characterization data set using data 

related to a grouping of at least some of the plurality of 
service packets corresponding to an occurrence of at 35 
least one of the first and second transaction types. 

16. The method of claim 9, further comprising: 
comparing the communications data set with a pattern 

characterization data set to determine whether at least ^ 
some of the collection of said plurality of service 
packets correspond to an occurrence of at least one of 
the first and second transaction types. 

17. A system for analyzing the transmission of a plurality 
of service packets along a communications line, wherein a 45 
communications data set includes information relating to an 
ordering of a collection of the service packets, the service 
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packets corresponding to a plurality of service requests, 
wherein the information includes a lime interval between 
pairs of adjacent service requests, comprising: 
selection means for selecting a plurality of selected time 
intervals; and 

comparison means for comparing each of the time inter- 
vals between pairs of adjacent service requests with 
each of the plurality of selected time intervals to 
identify a plurality of sequences of the service requests 
corresponding to a plurality of transactions, with each 
of the sequences corresponding to one of the plurality 
of selected time intervals, wherein when the time 
interval between a selected pair of adjacent service 
requests is no more than at least one of the selected time 
intervals, the selected pair of adjacent service requests 
is considered to be part of a common transaction. 

18. The system of claim 17, further comprising: 
selecting means, in communication with said comparison 

means, for selecting a selected time interval based on 
the relationships between the number of occurrences of 
each of the plurality of sequences and the correspond- 
ing selected time interval. 

19. The system of claim 17, further comprising: 
identification means, in communication with said selec- 
tion means, for identifying at least one of a service 
request packet and service completion packet in said 
plurality of service packets using the contents of said 
service packets. 

20. The system of claim 17, further comprising: 
formation means for forming a pattern characterization 

data set using data related to a grouping of at least some 
of the plurality of service packets related to an occur- 
rence of one of the transactions, the formation means 
being in communication with the comparison means. 

21. The system of claim 17, further comprising: 
matching means for comparing the plurality of service 

packets and the ordering thereof against a predeter- 
mined ordering of service packets relating to one of the 
transactions. 

22. The system of claim 17, wherein, when the time 
interval between a selected pair of adjacent service requests 
is no more than one of the selected time intervals, the 
selected pair of adjacent service requests is considered to be 
a part of a common one of the transactions. 
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